Skip to main content
This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal

HCL Notes/Domino 8.5 Forum (includes Notes Traveler)

HCL Notes/Domino 8.5 Forum (includes Notes Traveler)

Previous Next

Your shoes may be screwed on too tight.

I'm not sure what your application does, but I'm envisioning something like our internal bug reporting database, where a tester validates that the problem is real, and then a developer gets to work on it. I can tell you technically how to accomplish what you're asking for, but unless there's a serious security reason for preventing users from adding value to the document by clarifying the contents of rich text fields, adding supplemental information, etcetera, you should not block them from editing it.

The way to prevent users editing the document without using your buttons is as I've said, by means of the Queryopen and Querymodechange events. Since regular editing is presumably allowed at some times, these events would have to check the values of some fields and set Continue=False if regular editing is not appropriate at the moment.

Your "Validate" button then would not bother to put the document in edit mode. It could just use back-end methods to change field values, save the document in the back end (NotesDocument.Save as opposed to NotesUIDocument) and close it (then reopen it, if that is a requirement).

Or, if for whatever reason you do want the document in edit mode, the Validate action, written in LotusScript, could set a global variable as a signal to the Querymodechange code that entering edit mode is authorized at this time.

The controlled access section idea someone else suggested, is also not a bad way to do it, depending on the application.

Another option, if you require extra security (because people can write code to modify any fields in documents to which they technically have access), is to use the access controls, but have server agents with special privileges. These agents can be run via RunOnServer, passing them a noteID as argument, to accomplish specific, restricted access tasks that users don't have the authority to do otherwise. They would, of course, have to include their own security, checking whether the person calling them is allowed to request the action in question (Reader lists on the agent design note would also take care of this, but can make it tricky to maintain the database design as you have to worry about whether the design notes are visible to the developers).


Feedback response number AGUD8NHR25 created by ~Julia Prefootherlen on 11/11/2011

Disable double-click to edit (~Lisa Fezjumiso... 11.Nov.11)
. . Maybe a section with controlled acc... (~Fred Asatumibu... 11.Nov.11)
. . The doubleclick setting is a client... (~Bill Frokimari... 11.Nov.11)
. . . . RE: Disable double-click to edit (~Lisa Fezjumiso... 11.Nov.11)
. . . . . . Your shoes may be screwed on too ti... (~Bill Frokimari... 11.Nov.11)
. . . . . . . . Thanks a lot for your help ! (~Lisa Fezjumiso... 14.Nov.11)
. . Sub Querymodechange (~Sigmund Dworel... 11.Nov.11)
. . Some other ideas (~Martha Lopjipy... 14.Nov.11)




Printer-friendly

Search this forum

Member Tools


RSS Feeds

 RSS feedsRSS
All forum posts RSS
All main topics RSS